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(54) Money validation 

(57) A money validator for example a coin validator, 
stores a boot program and a validation program. The 
boot program is run on power-up of the validator, checks 
for the presence of a validation program and transfers 
control to the validation program if one is found. Other- 
wise, the boot program continues to run, and includes 



a communications routine to allow installation of a vali- 
dation program. The validation program can transfer 
control to the boot program to permit data to be trans- 
ferred using any one of a plurality of different communi- 
cations ports, and this data can be used to re-configure 
the validator, for example by changing stored accept- 
ance criteria. 
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Description 

[0001] This invention relates to methods and appara- 
tus for validating units of money, and to methods for con- 
figuring and re-configuring such apparatus. The inven- 
tion will be described primarily in the context of coin val- 
idators, but is also applicable to other apparatus such 
as banknote validators. 

[0002] Electronic coin validators are often microproc- 
essor controlled. The microprocessor either contains or 
is connected to a memory circuit which contains pro- 
gram code and data which are used in the validation of 

coins. 

[0003] It is known to use replaceable memory circuits 
to permit the program of the validator to be upgraded. It 
is also known to use memory circuits which store alter- 
able contents, so that the operation of the validator can 
be adjusted. For example, it is known to alter data rep- 
resenting acceptance criteria used to determine wheth- 
er an inserted coin is a valid coin of a particular denom- 
ination. This allows the validator to be re-configured, or 
reprogrammed, to handle different denominations of 
coins from those which the validator was originally con- 
figured to accept. Alterable data may be stored in a sep- 
arate memory circuit to facilitate alterations, such as an 
EAROM (electrically alterable read only memory). 
[0004] To change the memory contents, it is neces- 
sary for the validator to have means permitting suitable 
connections to be made to the memory to allow the con- 
tents to be altered by external apparatus. This external 
apparatus may directly change the contents of the mem- 
ory by means of this connection. In other known ar- 
rangements a communications port is provided for the 
external apparatus to communicate with the microproc- 
essor for various purposes, including the reading-out of 
various operational parameters of the program. This 
port can additionally be used to instruct the microproc- 
essor to alter the contents of the memory circuit. 
[0005] Coin validators also have communication ports 
for other purposes. For example, there may be a port 
for communicating with a host vending machine in which 
the coin validator is located, a port for communication 
with other transaction equipment, such as a banknote 
validator, or a port permitting transaction data to be 
downloaded from the coin validator. 
[0006] Various aspects of the invention are set out in 
the accompanying claims. 

[0007] According to one aspect of the invention, a 
control means, which may include a microprocessor, for 
a money validator is operable to receive data from any 
selected one of a plurality of communication ports, and 
to use the received data to replace memory contents 
used in the validation operation performed by the vali- 
dator. Thus, re-configuring of the validator is facilitated, 
because the re-configuration operation can be per- 
formed using the most suitable port, having regarding 
for example tothe speed of communication, physical ac- 
cess to the port, etc. The re-programming may take 



place using a different port from that (if any) used in the 
original factory configuration of the validator. 
[0008] According to a further aspect of the invention, 
a control means for a money validator has memory 

5 means (which may be a single circuit or multiple circuits) 
having first contents comprising a boot program and 
second contents defining a validation operation and 
comprising a validator program, the boot program being 
operable independently of the presence of the validation 

io program and including a communications routine, the 
boot program being arranged to be executed on initia- 
tion of the operation of the validator, being selectively 
operable to transfer control to the validation program, 
and also being capable of using the communications 

is routine to receive externally -supplied data and to use 
this data to replace at least some of the second memory 
contents. Preferably, the validation program is respon- 
sive to at least one command to relinquish control to the 
boot program; in this way, the boot program can be ar- 

20 ranged automatically to relinquish control on initialisa- 
tion, e.g. power up, so that validation operations can 
commence, but nevertheless provision is made so that 
the boot program can regain control in order to permit a 
communication operation to take place in order to re- 

25 configure the validator. 

[0009] Preferably, these aspects of the invention are 
combined in a single embodiment. 
[0010] The re-configuration can be carried out in order 
to alter acceptance criteria. Alternatively or additionally, 

30 the re-configuration operation can be carried out to alter 
at least some of the program code forming the validation 
program. 

[0011] Preferably, the boot program is operable to 
scan a plurality of communication ports of the validator, 
35 to recognise that one of the ports is being used, e.g. by 
detecting data on that port, and thereafter to select that 
port and establish a communication operation using the 
selected port. 

[0012] Preferably, the boot program is arranged to 
40 check for the presence of a validation program before 
relinquishing control after the operation of the validator 
has been initiated. Preferably, the validation program is 
operable to relinquish control to the boot program on re- 
ceipt of a specific external command. Preferably, differ- 
45 ent commands can be provided using, e.g. a message 
on a communication port and/or an external switching 
means. 

[0013] Preferably the boot program and the applica- 
tion program occupy respective areas of a memory map, 
50 and preferably the communication program is arranged 
such that the area occupied by the boot program cannot 
be overwritten by received data. 

[0014] The invention also extends to a method of re- 
programming a validator in accordance with the inven- 
ts tion. 

[0015] An arrangement embodying the invention will 
now be described by way of example with reference to 
the accompany drawings, in which: 
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Fig. 1 schematically shows a coin validator in ac- 
cordance with the invention; and 
Fig. 2 is flowchart of the operation of the validator 

[001 6] Referring to Fig. 1 , a coin validator 2 comprises 
a hopper 4 for receiving coins which are directed to an 
acceptor unit 6. The acceptor unit is arranged to perform 
testing of inserted coins. Any that are deemed invalid 
are directed to a reject path 8, which returns the coins 
to the customer. Acceptable coins are directed by a sort- 
er 9 either to a cashbox (not shown) via a cashbox path 
10, or to storage regions 12, each of which comprises 
a tube for receiving a respective denomination of coins. 
Coins from the tubes can be selectively dispensed using 
a dispenser unit 14. 

[0017] The acceptor 6 has a control board 16 which 
is coupled to the various operational parts of the valida- 
tor, including the coin sensors (not shown), the dispens- 
er 14, various gates (not shown) in the sorter 9 which 
control the routing of the coins and further sensors, for 
example sensors to indicate when the tubes 12 are full. 
The circuit board carries a microprocessor 18 which is 
connected to a flash (E AROM) memory 20. The memory 
20 may be formed in the same integrated circuit unit as 
the microprocessor 18, or may be one or more separate 
circuit elements. 

[0018] The circuit board 16 is also connected to an 
input output unit 22 which has a keypad 24 and an LED 
indicator 26. 

[0019] The control board 16 is also connected to four 
serial ports. One serial port 28 is intended to allow serv- 
icemen to interrogate the circuit board to obtain a history 
of transact bns carried out by the validator. If desired, 
the port 28 may be in the form of an infra-red receiver 
transmitter for enabling communication with a similarly- 
equipped port on a downloading device carried by the 
service engineer. 

[0020] The coin validator is housed in a vending ma- 
chine (not shown), and a second of the ports, 30, is con- 
nected to a control board 32 of the vending machine. 
[0021] A third port 34 is connected to a bill validator 
36 also housed within the vending machine. 
[0022] A fourth port 38 is provided for communication 
with a detachable programming unit. 
[0023] Preferably, the port 28 is accessible without 
opening the vending machine, but the ports 30, 34 and 
38 are only accessible by opening the vending machine. 
The ports 30, 34 and 38 are preferably of standard 
types. For example, the port 30 may comply with (i) the 
Multi-Drop Bus (MDB), which transmits data using the 
protocol in the NAMA "Internal Multi-Drop Bus Interface 
Standard", (ii) the Executive Vending Machine Interface 
(Protocol A) of Mars, Inc., or (iii) the BDV standard 
BDV001 . The port 34 preferably comprises the MDB pe- 
ripheral standard. The port 28 may comply with the DEX 
or DDCMP communications standard according to the 
European Vending Association Data Transfer Standard, 
or be a standard printer port. The port 38 is preferably 



an HI I port, connected to the circuit board 16 via a bus 
corresponding to that disclosed in EP-A-584097. All 
these standard types of ports are well known to those 
skilled in the art of coin validators. 

s [0024] In prior art arrangements, the port 38 is used 
for re-configuring validators. For example, it is possible 
using the port 38 to communicate with the microproces- 
sor 1 8 in order to instruct the microprocessor to replace 
stored data representing acceptance criteria with further 

10 data transmitted via the port 38. Any data transmitted 
from the port 38 complies with a known protocol, which 
involves transmitting a command and data. 
[0025] The circuit board 16 carries : or is connected 
to, electrical contacts which can be selectively bridged 

is by a detachable connector 40. By selectively attaching 
the connector 40, it is possible to provide commands to 
the validator, the nature of the command depending up- 
on which contacts are bridged by the connector. In the 
preferred embodiment, the connector is a plug having 

20 contacts mating with those on the validator, the contacts 
on the plug being selectively interconnected using a wire 
loom. The connector is carried by a service engineer 
and may be used to instruct the validator to accept a re- 
programming operation. The connector can be fitted on- 

25 |y by opening the vending machine and partly disassem- 
bling the coin validator (in particular by unfastening and 
pivoting the acceptor unit 6 away from the remainder of 
the validator). 

[0026] Referring to Fig. 2, this illustrates the operation 
30 which the validator carries out in response to programs 
stored in the flash memory 20. The memory map of the 
flash memory 20 contains a lower-address area and an 
upper-address area. The lower-address area contains 
a program routine which is executed on power- up of the 
35 microprocessor 18. This area contains a boot program 
which performs all the operations shown in Fig. 2 except 
for those shown within the program block 220. The up- 
per-address area contains a validation program and as- 
sociated data, which are used in the validation operation 
40 performed by the coin validator. The routines performed 
by the program code in the upper-address area are con- 
tained within the block 220. 

[0027] Following power- up, at step 240, the boot pro- 
gram proceeds to an initialisation routine at step 242. 

45 Various initialisation operations are carried out here, in- 
cluding causing the LED 26 to display a red indication. 
Then, at step 244, the program examines the contents 
of the upper-address memory to determine whether an 
application program is present in that area. If so, the pro- 

50 gram proceeds to step 246. This part of the program 
checks the contents of the upper-address memory area 
to determine whether the application program should be 
deemed valid. This can be done in a number of ways, 
including performing processing of the stored contents 

55 to compare the results of the processing with stored 
checksums. 

[0028] If no valid application is found in the upper-ad- 
dress memory area, the boot program proceeds from 
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step 244 or 246 to step 248. Thus, step 248 is reached 
either in response to an external instruction from a serv- 
ice engineer authorised to open the vending machine, 
or if no valid application program is present on power- 
up. The step 248 involves scanning all four of the com- 
munication ports 28, 30, 34 and 38 to determine whether 
any data is present on those ports. This routine is re- 
peatedly performed until data is found, when the pro- 
gram proceeds to step 250. At this step, the LED 26 is 
caused to provide an alternating red/green display. The 
port on which the data has been found is selected as 
the port used for a communication operation. 
[0029] Otherwise, assuming that the application is 
deemed valid, the boot program relinquishes control to 
the validation program 220. The validation program at 
step 220 includes a main validation routine 210 which 
will not be described in detail as it may be very similar 
to those executed by current validators, and which will 
be known to those skilled in the art. However, the vali- 
dation program also checks for certain conditions, at 
step 212, 214 and 216, and if any of those conditions 
are met, the validation program relinquishes control 
back to the boot program, so that the program execution 
proceeds from the appropriate one of the steps 212 to 
216 to step 248. 

[0030] At step 212 the validation program checks to 
see whether a connector 40 of an appropriate configu- 
ration has been fitted. 

[0031] At step 214, the validation program checks to 
determine whether a "reprogram" command has been 
received from a communication port. Preferably the pro- 
gram checks the reprogramming port 38, but it may ad- 
ditionally check one or more of the other ports. 
[0032] At step 21 6, the validation program determines 
whether the keypad 24 has been operated in a prede- 
termined way, which constitutes a reprogramming com- 
mand. 

[0033] Although the flowchart of Fig. 2 suggests that 
these three checking operations are performed in se- 
quence, as part of a main program loop involving the 
validation operation, this is not essential. For example, 
the checking operations can be performed in response 
to interrupts. 

[0034] In operation, a service engineer will open the 
vending machine and then connect a portable re-con- 
figuration device (which may be in the form of a standard 
PC-type computer with a standard communications 
port) to a selected port of the validator, if necessary un- 
plugging the connection to port 30 or 34. The port may 
be selected according to convenience, taking into ac- 
count the type of connectors available to the engineer, 
the speed of the port (as some ports may be faster than 
others), ease of access, etc. The engineer then instructs 
a reprogramming operation by either fitting the connec- 
tor 40, operating the keypad in a predetermined way or 
issuing a command via a communications port. This re- 
sults in control of the operation being relinquished by 
the validation program 220 to step 248 of the boot pro- 



gram. 

[0035] Then, at step 252, the program repeatedly ex- 
ecutes a routine to check for a received command from 
a selected port. When that command has been re- 

s ceived, the program proceeds to step 254 and then ei- 
ther to step 256 or to step 258 depending upon whether 
a valid application is present in the upper memory area. 
Assuming that a valid application is present, the pro- 
gram proceeds to step 256; this can only have been 

10 reached if the valid application has relinquished control 
to the boot program. At step 256, the LED 26 is caused 
to display a flasning amber colour. Otherwise, at step 
258, the LED 256 is caused to alternate between green 
and amber colours. Step 258 will be reached only if no 

15 valid application was found on powe ;p. Thus, the LED 
indicates whether or not the commit itcations operation 
which is about to start will upgrade an existing applica- 
tion. 

[0036] The program then proceeds to step 260 to de- 
20 termine the command which has been sent on the se- 
lected communication port. 

[0037] There then follow a number of steps 262, 264, 
266 and 268 : which are carried out in order to check 
whether the received command corresponds to one of 

25 four types of commands. In practice, there would prob- 
ably be more than four possible commands, in which 
case as indicated by path 269 additional steps to those 
shown in Fig. 2 would be provided to check for these 
further commands. 

30 [0038] Step 262 checks for a "run validation program" 
command. If this has been provided, then the boot pro- 
gram relinquishes control to the application program at 
step 220. 

[0039] Otherwise, at step 264, the boot program 

35 checks to determine whether the received command is 
a command to download data. If so, at step 270, a com- 
munication operation is performed on the selected com- 
munications port. This may use any standard commu- 
nications routine, such as the XMODEM protocol. 

40 [0040] The data received during this communication 
operation is stored in the flash memory, in regions of the 
upper memory address area determined by the param- 
eters sent over the communications port with the down- 
load command. These contents can therefore overwrite 

45 part or all of the validation program stored in the upper 
memory area, or part or all of the data used by the val- 
idation program and also stored in the upper memory 
address area. Typically, this data may form acceptance 
criteria for the coins to be validated by the validator. 

50 [0041] Following the download operation, the pro- 
gram proceeds to step 260 again, in order to obtain the 
next command. If this is a "run application" command, 
the program proceeds from step 262 to the application 
program at step 220, so that the re-configured validation 

55 program can be run. 

[0042] The other commands checked for at steps 266, 
268, etc. result in operations performed at steps 272, 
274, etc. One command may for example be a request 
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for the boot program to send over the selected port a 
message indicating the maximum communications 
speed for that port. Another command may be an in- 
struction to the boot program to change the set commu- 
nication speed for the selected port to a particular value. 
These commands allow the speed of communication to 
be altered as desired by the equipment coupled to the 
selected communications port. 

[0043] Thus, an engineer can cause a communication 
operation to take place to download data from his port- 
able reprogramming equipment. The engineer then is- 
sues a "run application" command to re-start the re-con- 
figured validation operation, and then disconnects his 
equipment. 

[0044] It will be appreciated from the above that the 
validation program 220 can be completely replaced us- 
ing this technique. The boot program is so arranged that 
it does not permit overwriting of the lower memory-ad- 
dress area. Nevertheless, it is possible to upgrade the 
boot program in the following manner. First, the valida- 
tion program is replaced by a new program correspond- 
ing to the boot program except without any limitation on 
the memory address areas to which data can be written. 
Then the original boot program relinquishes control to 
the newly-downloaded program. This then performs a 
communication operation to download a new boot pro- 
gram which is stored in the lower memory address area. 
Then control is relinquished to this newly-downloaded 
boot program. At that point, the original (or a new) vali- 
dation program can be downloaded by the upgraded 
boot program. 

[0045] It is well known to take measurements of coins 
and apply acceptability tests to determine whether the 
coin is valid and the denomination of the coin. The ac- 
ceptability tests are normally based on stored accepta- 
bility data. One common technique (see, e.g. GB-A-1 
452 740) involves storing "windows", i.e. upper and low- 
er limits for each test. If each of the measurements of a 
coin falls within a respective set of upper and lower lim- 
its, then the coin is deemed to be acceptable. The ac- 
ceptability data could instead represent a predeter- 
mined value such as a median, the measurements then 
being tested to determine whether they lie within prede- 
termined ranges of that value. Alternatively, the accept- 
ance data could be used to modify each measurement 
and the test would then involve comparing the modified 
result with a fixed value or window. Alternatively, the ac- 
ceptance data could be a look-up table which is ad- 
dressed by the measurements, and the output of which 
indicates whether the measurements are suitable for a 
particular denomination (see, e.g. EP-A-0 480 736, and 
US-A-4 951 799). Instead of having separate accept- 
ance data for each test, the measurements may be com- 
bined and the result compared with stored acceptance 
data (cf. GB-A-2238152 and GB-A-2 254949). Alterna- 
tively, some of these techniques could be combined, e. 
g. by using the acceptance data as coefficients (derived, 
e.g. using a neural network technique) for combining the 
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measurements, and possibly for performing a test on the 
result. A still further possibility would be for the accept- 
ance data to be used to define the conditions under 
which a test is performed (e.g. as in US-A-4 625 852). 

5 [0046] It is known to use statistical techniques for de- 
riving the data, e.g. by feeding many items into the val- 
idator and deriving the data from the test measurements 
in a calibration operation. It is also known for the valida- 
tor to have an automatic re-calibration function, some- 

io times known as "self-tuning", whereby the acceptance 
data is regularly updated on the basis of measurements 
performed during testing (see for example EP-A-0 155 
126, GB-A-2 059 129, and US-A-4 951 799). 
[0047] Normally, the acceptance data produced by 

15 the calibration operation is characteristic of the specific 
type of item to be validated. However, it is alternatively 
possible for the data to be independent of the properties 
of the item itself, and instead to be characteristic of just 
the validation apparatus (e.g. to represent how much the 

20 apparatus deviates in its measurements from a stand- 
ard) so that this data in combination with further data 
representing the standard properties of an item are suf- 
ficient for validation. 

[0046] The acceptance criteria stored in the upper 
2S memory area of the above-described embodiment may 
take any of the forms indicated above, and it will be ap- 
preciated that the present invention provides a conven- 
ient way of altering such criteria. 

30 

Claims 

1 . A money validator having a control means which is 
operable to receive data from any selected one of 
35 a plurality of communication ports of the validator, 
and to use the received data to replace memory 
contents used in the validation operation performed 
by the validator. 

40 2. A money validator having a control means including 
memory means having first contents comprising a 
boot program and second contents defining a vali- 
dation operation and comprising a validation pro- 
gram, the boot program being operable independ- 

45 ently of the presence of the validation program and 
including a communications routine, the boot pro- 
gram being arranged to be executed on initiation of 
the operation of the validator, being selectively op- 
erable to transfer control to the validation program, 

50 and also being capable of using the communica- 
tions routine to receive externally-supplied data and 
to use this data to replace at least some of the sec- 
ond contents. 

55 3. A money validator as claimed in claim 2, wherein 
the boot program is arranged to check for the pres- 
ence of a validation program before transferring 
control after the operation of the validator has been 
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initiated. 

4. A money validator as claimed in claim 2 or claim 3, 
wherein the validation program is responsive to at 
least one command to transfer control to the boot 
program. 

5. A money validator as claimed in claim 4, wherein 
the validation program is operable to transfer con- 
trol to the boot program on receipt of a predeter- 
mined message from a communication port of the 
validator. 

6. A money validator as claimed in claim 4 or claim 5, 
wherein the validation program is operable to trans- 
fer control to the boot program in response to an 
external switching means. 

7. A money validator as claimed in any one of claims 
2 to 6, wherein the first and second contents occupy 
respective areas of a memory map. 

8. A money validator as claimed in claim 7, wherein 
the communications routine is arranged such that 
the area occupied by the boot program cannot be 
overwritten by received data. 

9. A money validator as claimed in claim 8, wherein 
the communications routine is operable to use the 
externally-supplied data to write a second commu- 
nications routine into the second contents area of 
the memory means and to transfer control to the 
second communications routine, the second com- 
munications routine being operable to receive fur- 
ther externally-supplied data and to use th is to over- 
write at least part of the boot program so as to up- 
grade the boot program. 

10. A money validator as claimed in any one of claims 
2 to 9, wherein the control means is operable to re- 
ceive the externally-supplied data from any select- 
ed one of a plurality of communication ports of the 
validator. 



validation operation. 

14. A coin validator as claimed in any preceding claim. 

5 15. A banknote validator as claimed in any one of 
claims 1 to 1 3. 

16. A method of re-programming a money validator as 
claimed in any one of claims 1 to 1 3. 

10 

17. A method of re -configuring a money validator as 
claimed in any one of claims 2 to 1 1 , comprising is- 
suing an instruction to transfer control to the boot 
program and then supplying data using the commu- 

is nications routine. 

18. A method of re-programming a money validator 
having a plurality of communications ports each ca- 
pable of receiving re-programming data, the meth- 

20 od comprising selecting one of the communication 
ports, causing the validator to execute a communi- 
cations routine, and transferring data to the valida- 
tor such that the data is received by the communi- 
cations routine and can thus be used to replace ex- 

2B isting memory contents of the validator defining the 
configuration of the validator. 

19. A method as claimed in claim 1 8, wherein the step 
of causing the validator to execute a communica- 

30 tions routine comprises issuing a command using 
the selected communications port. 

20. A method as claimed in any one of claims 17 to 1 9, 
including transmitting to the validator data defining 

35 acceptance criteria. 



40 



11. A money validator as claimed in claim 1 or 10, 45 
wh erein the control means is operable to scan a plu- 
rality of communication ports of the validator, to rec- 
ognise that one of the ports is being used, and in 
response thereto to select that port and establish a 
communication operation using the selected port. so 

12. A money validator as claimed in any preceding 
claim, wherein the control means is operable to use 
received data to replace stored acceptance criteria. 

55 

13. A money validator as claimed in any preceding 
claim, wherein the control means is operable to use 
received data to replace program code used in the 
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